The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, whether or not a given approach is prior art, the problems identified with that approach should not be assumed to have been recognized in the prior art.
In a database management system (DBMS), data is stored in one or more data containers, each container contains records, and the data within each record is organized into one or more fields. In relational database systems, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
Systems that implement the present invention are not limited to any particular type of data container or database architecture. However, for the purpose of explanation, the examples and the terminology used herein shall be that typically associated with relational databases. Thus, the terms “table”, “row” and “column” shall be used herein to refer respectively to the data container, record, and field. The present invention is not limited to any particular type of data container or database architecture. However, for the purpose of explanation, the examples and the terminology used herein shall be that typically associated with relational databases. Thus, the terms “table”, “row” and “column” shall be used herein to refer respectively to the data container, record, and field.
A database server retrieves and manipulates data in response to receiving a database statement. Typically the database statement conforms to a database language, such as Structured Query Language (SQL). A database statement can specify a query operation, a data manipulation operation, or a combination thereof. A database statement that specifies a query operation is referred to herein as a query. The present invention is not limited to database statements that specify a particular type of operation. However, for the purpose of explanation, embodiments of the present invention are illustrated using queries.
One function of a database server is to control access to database data. Security mechanisms on database servers control what data may be accessed by a query issued by a user. One type of security mechanism is referred to as a fine-grained access control mechanism. An example of fine-grained access control is described in U.S. Pat. No. 6,487,552, issued Nov. 26, 2002 to Chon Hei Lei et al, which is incorporated herein by reference in its entirety. Fine-grained access control may be used to grant and/or deny access to one or more rows of a table.
According to an embodiment of Chon Hei Lei et al. a mechanism is provided for dynamically attaching predicates to queries, where the predicates are attached based on a policy. For example, the database system detects that a query is issued against a database object. Prior to executing the query, a policy function associated with the database object is invoked. The policy function creates a modified query by selectively adding zero or more predicates to the query based on a policy associated with the database object. The modified query is then executed.
For example, an executive may want to see a list of employee names and their salaries available in an employee_name column and employee_salary column of an EMPLOYEE table. Consequently, the executive may submit the query                SELECT employee_name, employee_salary FROM employee;However, the executive may only be entitled to view the information in the EMPLOYEE table that pertains to employees within his department. Consequently, (without notifying or alerting the user) a predicate may be appended to the query, such as        WHERE department=My_department(USER_ID)Effectively, the resulting modified query becomes        SELECT employee_name, employee_salary FROM employee        WHERE department=My_department(USER_ID);The modified query returns only the names and salaries of the employees within the executives department in accordance with the security policy.        
Data in some database objects is valuable when combined with data in another object. For example, in a data warehouse environment, fact tables are combined with dimension tables for analyzing customer data. In payroll, salary information is only meaningful when an employee ID can be traced to an employee's name. In contrast, today's fine-grained access control technology applies policies on a per table basis. Consequently, the simplest way to protect the viewing of the combined information is to prevent the user from viewing either table. However, limiting the access on a per table basis greatly limits what kind of security policies can be enforced at an application level.
Based on the forgoing, it is desirable to provide a more flexible method of protecting information derived from multiple tables.